With the continuing evolution of network computing, distributed applications utilizing a client/server computing model have become quite prevalent. Server-based, or web applications, have become a primary purveyor of distributed computing resources to client users connected to web servers and other servers through a network.
Applications that execute on a server require reloading and reinitialization when the underlying software code is revised or when the application configuration is revised. Furthermore, the server may be in the midst of processing requests on behalf of users for the revised application while the application is being reloaded or reinitialized.
One prior approach to reconfiguring a server-based application upon an application revision is to stop the server from processing, reload the revised application and reconfigure the server accordingly, and then restart the server in order to implement the changes made to the application and the server. This approach has numerous shortcomings, one of which is the fact that the server cannot process requests for the revised application, or any other application installed on the server, while it is off-line or in the process of restarting. Requests that are in progress when the server is restarted may be interrupted, which typically leads to request processing errors. Furthermore, any server down-time adversely affects the availability of the server, which in turn may have an impact on, for example, SLAs (Service Level Agreement) associated with the services provided by the server.
Other shortcomings of this approach are due to the fact that large servers typically have multiple applications executing, thus an application maintenance operation requiring server stop/restart each time an application is changed is not a viable approach for a high-traffic server, partly due to the time it takes to restart a server running multiple applications. Again, while the server is off-line and while being restarted, users may be denied access to the server. A complex server can take on the order of minutes to restart. In terms of request traffic, several minutes is an extremely long time, and a tremendous amount of traffic can be lost in that time. Many servers, such as those servicing commercial websites, cannot afford to have this amount of down time. In addition, discovery of an error in the new application configuration subsequent to the reload requires another server stop/restart. Yet another shortcoming to note is that interrupting requests that are in progress by restarting the server likely compromises the integrity of the data associated with the current user sessions, which leads to errors when the sever resumes its request processing.
Another prior approach to reconfiguring a server-based application is to configure the server to periodically check the application class files for revisions thereto. Using this approach, the timestamp associated with each application class file is stored when starting the server and thus reloading the application. Upon an application service request, the server checks to see if a predetermined time interval has expired, and if it has, the server compares the timestamp of each class file stored on disk with the associated timestamp that the server had when it started. If the two timestamps are different, then the application class files are reloaded to ensure the that the current version of the application is being used to process requests.
This approach also has numerous shortcomings, one of which is that changes to the application configuration files, which are key application components, are not detected. This approach only detects changes to the application code, for example, the Java source code that is compiled into the application class files. Furthermore, any changes to the container, or runtime environment, in which the application is running, are also not detected. This is a bad situation because, typically, configuration changes to a container which directly or indirectly affect the application must cause the application to be reloaded and reinitialized so that the configuration used by the server reflects the current configuration of the application and the container. This approach does not facilitate such a process. Another shortcoming to this prior approach is that a server administrator typically waits for the predetermined time to elapse, and thus changes to the application are not detected until expiration of the time interval. Hence, one might have to wait to verify that the revised application is executing and functioning properly. Yet another shortcoming is that each time the periodic check is performed, it produces a negative impact on server performance.
The current methodology for reconfiguring a server leaves much to be desired. In light of the foregoing, there is a clear need for an improved server-based application reconfiguration mechanism.